REMARKS 

Claims 1-3, 5-12, 15, 16, 18, 19, 21 and 23-25 are currently pending, with claims 1, 7 and 11 
being in independent form. No new matter has been added. Reconsideration of the application is 
respectfully requested. 

The Examiner has failed to indicate Applicant's claim for priority or that the U.S. Patent 
Office has received the priority documents. A notice indicating Applicant's claim for priority and 
that the priority document was received is requested. 

In the May 9, 2006 Office Action, independent claims 1, 7 and 11, and dependent claims 2, 
3, 5, 8-10, 12, 15, 16 and 23-25 were rejected under 35 U.S.C. §103(a) as unpatentable over 
"Design of Interfaces for TCP/IP Over Wireless," IEEE, 1996 ("Chaskar") in view of "Gateways 
and RFCN (Reverse Feedback Congestion Notification)," IEEE, Feb. 5, 1997 ("Ziegler") or U.S. 
Patent No. 6,438,101 ("Kalampoukas"). Claims 6, 18, 19 and 21 were rejected under 35 U.S.C. 
§103(a) as unpatentable over Chaskar or Ziegler, and further in view of U.S. Patent No. 6,608,832 
^Forslow"). For the following reasons, it is respectfully submitted that all claims of the present 
application are patentable over the cited references. 

Chaskar discloses an analytical framework for estimating TCP performance using link 
layer error recovery, taking into account specific wireless characteristics and the size of a 
wireless-wireline interface buffer (see Abstract; pg. 200, left column, 1 st ^f). Chaskar (Abstract) 
states, "TCP has been recently shown to perform poorly in the presence of random loss, its 
performance over a lossy wireless link which is subject to fades and other impairments may be 
unsatisfactory. Chaskar thus teaches that applying the wireline TCP congestion control 
mechanism to a wireless channel causes problems. 

Chaskar (pg. 199, 2 nd paragraph) states, "buffer overflow at the interface leads to the 
occurrence of loss being seen by the end-to-end protocol and a consequent reduction in window 
size. This phenomenon would not be a problem if TCP could actually cut back its window in 
response to a bad state for the wireless channel, and then could increase it back rapidly to take 
advantage of a good state. However, feedback delay . . . [implies] that TCP cannot keep up with 
the fluctuations of a typical wireless channel. Thus, without some additional mechanism, TCP 
performance over a wireless link could be disastrous". Chaskar, however, fails to teach or 
suggest any additional mechanism. Rather, Chaskar teaches an analytical framework for 
predicting TCP performance. 
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In contrast, the claimed invention solves the problem described in Chaskar by a network 
element which is arranged to buffer data packets transmitted by a sender, examine and modify 
the header data, detect transmission conditions comprising buffering conditions of data packets 
at the network element and radio conditions and modify the window size accordingly . Chaskar 
fails to teach or suggest such a claimed network element, as recited in independent claim 1 . 

The Office Action (pgs. 3 and 5) states: 

The network element is arranged to modify the window size to 
a lower value when it detects decreasing quality of transmission 
conditions (Page 199, Sec 1, 2.2, 3, Abstract); implicitly teaches 
that the network element is arranged to quit modifying the window 
size when it detects that the quality of the transmission conditions 
is increasing and allow the receiver to set the window size 
normally (Page 199, Right col., First and second Par). 

However, Applicant respectfully asserts that it is not possible based on the teachings of 
Chaskar to derive that the interface buffer size is modified in accordance with channel conditions 
detected by a network element. Chaskar merely teaches that TCP is not able to quickly follow 
wireless channel fluctuations and that an additional mechanism is needed. However, there is 
nothing here with respect to the structure of Applicant's claimed network element. 

The Examiner acknowledges that Chaskar differs from the claimed invention in that 
Chaskar fails to teach a receiver that is arranged to acknowledge each received data packet by an 
acknowledgment message containing header data. The Examiner cites Zielger or Kalampoukas 
in an attempt to cure this deficiency of Forslow (Office Action, pgs. 3 and 5, respectively). 
However, the combination of Chaskar and Zielger or Kalampoukas fails to teach or suggest the 
limitation "transmission conditions comprising buffering conditions of data packets at [a] 
network element and radio conditions ," as recited in independent claims 1, 7 and 11. 

Ziegler discloses a Buffer Utilization Control (BUC) algorithm that is executed in a 
"gateway" (see pg. 410, Abstract). Ziegler (pg. 410, Abstract, lines 12-13) discloses a signaling 
mechanism called Reverse Feedback Congestion Notication (RFCN). Ziegler (Abstract, lines 14- 
15) teaches that RFCN is applicable to transport protocols, such as TCP. Ziegler (Abstract, lines 
15-17) teaches a receiver transmits its available buffersize to a sender in a window-field in the 
header of an ACK-header during window flow control. Zeigler (Abstract, lines 17-20) teaches that 
the BUC algorithm may update the credit value in this window field to its computed window to 
control the transmission rate of a data-sender. In short, the BUC gateway disclosed in Ziegler is 
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unable to detect radio conditions. Zeigler thus fails to teach or suggest independent claims 1, 7 and 
11. 

Ziegler (pg. 41 1, 1 st paragraph) teaches that the main goal of BUC is to keep the overall 
utilization at an output-port in a desired range, and while achieving this, provide fairness to 
controlled conversations. Ziegler (pg. 41 1, 1 st paragraph) states the BUC algorithm computes a 
window depending on the state of a conversation's queue during a well defined time interval in 
order to control the flow of conversations. However, Ziegler fails to teach or suggest that 
transmission conditions comprising buffering conditions of data packets at a network element and 
radio conditions are detected, as recited in independent claims 1, 7 and 11. 

Ziegler (pg. 411, 2 nd paragraph) teaches that each conversion maintains two per- 
conversation-queues at two distinct output-ports at the BUC gateway. Ziegler (pg. 411, 2 nd 
paragraph, lines 3-5) states, "from the viewpoint of a data-sender, one of these per-conversation- 
queues is the 'forward queue', i.e., the queue storing the packets sent by the data sender". Ziegler 
(pg. 41 1, 2 nd paragraph, lines 3-5) states, "the other queue storing the other per-conversation-queue 
is the 'backward queue', i.e., the queue storing the ACKs to be received by the data-sender". 
Ziegler (pg. 411, 2 nd paragraph, lines 7-9) states, "the RFCN algorithm requires that each forward 
queue have access to the data structures of its corresponding backward queue and vice versa". 
Ziegler (pg. 41 1, 2 nd paragraph, lines 9-13; Fig. 1) teaches that if used in combination with RFCN, 
the BUC algorithm calculates the window at the forward queue and sets the header field of the 
ACKs at the corresponding backward queue. There is nothing in the foregoing sections of Zeigler 
to teach or suggest anything associated with radio conditions , or otherwise. 

Kalampoukas, on the other hand, teaches a method for controlling congestion in an 
internetwork having at least one controlled network segment and at least one non-rate-controlled 
network segment coupled by a router to prevent large queues of packets from accumulating in 
the router, thereby potentially causing congestion and buffer overflows in the routers (see col. 2, 
line 63 thru col. 3, line 1). Kalampoukas (col. 3, lines 1-5) states, "the window size of 
connections passing through the routers are controlled based on the congestion level in the 
routers, so as to control the flow of packets into the internetwork, thereby controlling 
congestion". Kalampoukas (col. 3, lines 5-7) teaches that this results in improved throughput 
and fairness in the internetwork while minimizing losses due to buffer overflows in the routers. 
However, Kalampoukas fails teach or suggest the limitation "transmission conditions comprising 
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buffering conditions of data packets at Tal network element and radio conditions ," as recited in 
independent claims 1, 7 and 11. 

Kalampoukas (col. 10, lines 24-28; Fig. 6) teaches destination device 125 sends an 
acknowledge for the packet having byte 21000 with a window size value of, for example, 8000 
bytes, in the case where destination communication device 125 successfully receives the data 
packets with a byte range of 20001-21000. However, there is nothing here to teach or suggest all 
of the limitations recited in independent claims 1, 7 and 11. That is, the routers disclosed in 
Kalampoukas are also unable to detect radio conditions. 

Forslow has been cited by the Examiner based on the failure of Chaskar, Ziegler and 
Kalampoukas to teach or suggest that the " network element comprises an SGSN network element 
for performing header compression". However, Forslow also fails to teach or suggest the limitation 
"transmission conditions comprising buffering conditions of data packets at [a] network element 
and radio conditions ," as recited in independent claims 1, 7 and 11. Consequently, the 
combination of Chaskar, Ziegler, Kalampoukas and/or Forslow fails to render independent claims 
1, 7 and 11 obvious and unpatentable and thus, reconsideration and withdrawal of all the rejections 
under 35 U.S.C. § 103(a) are in order, and a notice to that effect is requested. 

In view of the patentability of independent claims 1, 7 and 11, for the reasons set forth 
above, dependent claims 2, 3, 5, 6, 8-10, 12, 15, 16, 18, 19, 21 and 23-25 are all patentable over the 
prior art. 

Based on the foregoing amendments and remarks, this application is in condition for 
allowance. Early passage of this case to issue is respectfully requested. 

It is believed that no fees or charges are required at this time in connection with the present 
application. However, if any fees or charges are required at this time, they may be charged to our 
Patent and Trademark Office Deposit Account No. 03-2412. 




Respectfully submitted, 

COHEN, PONTANI, LIEBERMAN & PAVANE LLP 



KbgTNo, 43,559 
551 Fifth Avenue, Suite 1210 
New York, New York 10176 
(212) 687-2770 



Dated: August 1, 2006 
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